Copyright Notice
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings that form a part of this document: Copyright 2006-2008, eBay Inc., All Rights Reserved.
Technical Field
This disclosure relates to methods and systems supporting computing and data processing systems. More particularly, the disclosure relates to configuring a processing pipeline used to process request and response messages in a service-oriented architecture.
Related Art
In Service Oriented Architecture (SOA), there are typically many communicating reusable services that are deployed in several machines. In large-scale enterprises, like eBay, eTrade, or Google for example, there could be thousands of different services deployed in thousands of machines. It is most common and efficient for these services to communicate with each other. Further, external access is also typically provided for some of these services. In communicating with each other, various different types of communication protocols may be used for efficiently and optimization reasons. Communication between service providers and service consumers can be accomplished using some pre-defined protocol. In the web services case, this protocol can be the Simple Object Access Protocol (SOAP). SOAP is a protocol for exchanging Extensible Mark-up Language (XML)-based messages over computer networks, normally using Hypertext Transport Protocol (HTTP/HTTPS). SOAP often forms the foundation layer of the web services protocol stack providing a basic messaging framework upon which abstract layers can be built. There are several different types of messaging patterns in SOAP; but, by far the most common is the Remote Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to another node (the server) and the server immediately sends a response message to the client. In a typical SOA implementation, Service Consumers communicate with Service Providers using a specific underlying transport protocol (e.g., HTTP). There are several Message Exchange Patterns (MEP) for interactions between a service consumer and a service provider. In a Request-Response MEP, typically the response is sent back using the same transport the request was sent in. This typically requires the client to hold on to the connection until the response arrives, which could be inefficient and sometimes inconvenient depending on how long the processing of the request takes. It would be desirable, in some cases, to have the response come in potentially via a different transport (e.g., Simple Mail Transfer Protocol-SMTP). Further, most conventional SOA framework products require either use of the same transport for requests and responses in a request-response MEP, or require use of different message exchange patterns, such that responses are processed off-line and communicated via other means. For these reasons, it would be beneficial to decouple request and response processing, including their transports, for a request-response MEP, in a SOA. Additionally it is also beneficial to have the system support plugging in custom transports transparently for both requests and responses.
U.S. Patent Application No. 2005/0223109 describes a system wherein services such as product services, real-time services, and common services are deployed in a services oriented architecture. These services may, for example, be deployed for use in a variety of enterprise data integration functions.
U.S. Patent Application No. 2007/0011126 describes a service-oriented architecture (SOA) and accompanying method. In one embodiment, the SOA includes one or more service requesters coupled to one or more service providers via a bus. The bus includes runtime-binding functionality to facilitate interaction between the one or more service requesters and the one or more service providers. A registry, which stores information pertaining to a service provided by the one or more service providers, communicates with one or more service providers and/or requesters and the bus. In a more specific embodiment, bus includes a Service-Integration Bus (SIB) that includes a Service-Factory (SF) module for facilitating implementing the runtime binding functionality and for selectively invoking the service. Functionality of the SOA is strategically organized into various tiers and layers, including a requester tier, a provider tier, a business-process services tier, an infrastructure-services tier, an SIB layer, a persistence layer, and so on.
U.S. Patent Application No. 2005/0267947 describes a system including a service bus, which can act as an intermediary between a client and a service. Messages to the service bus arrive on a transport and can be processed to determine a destination to route and/or publish the message to, a transformation to perform on the message, and/or security processing. The message is then sent out on a transport bound for a service or another service bus. A response to the message can follow an inverse path through the service bus.
Thus, a computer-implemented system and method for decoupling processing of request and response messages supporting different pluggable respective transports in a service-oriented pipeline architecture is needed.